fix: add rail_confirmation_verified to PaymentReceipt (closes #327) - #335
fix: add rail_confirmation_verified to PaymentReceipt (closes #327)#335babyblueviper1 wants to merge 2 commits into
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
babyblueviper1
changed the title
|
recheck |
…onesty gap PaymentReceipt(status="Success") currently asserts payment success purely by producing psp_confirmation_id/network_confirmation_id -- the Python SDK's create_payment_receipt() self-generates both as a UUID with no payment-rail check, and the sample MPP server signs the result without ever calling out to a PSP or network. A downstream party has no way to distinguish "this receipt was independently confirmed against the rail" from "the issuer declared success and generated two IDs to match the schema." This adds an optional rail_confirmation_verified boolean to the Success receipt schema (additive, backward compatible -- absent/false is the exact behavior every existing caller already gets). create_payment_receipt() now accepts optional psp_confirmation_id/network_confirmation_id: omit them and nothing changes; supply real, rail-checked values and the receipt honestly reports rail_confirmation_verified=true. This does not attempt to make the SDK itself perform rail verification -- that's necessarily business/PSP-specific and out of scope for a spec-level receipt helper. It only stops the receipt from silently implying a check that never happened, generalizing the same present-vs-checked distinction already converged on in this repo's own negotiation-ref.md invariant 5, discussed with @giskard09 on google-agentic-commerce#327. Regenerated code/sdk/python/ap2/sdk/generated/payment_receipt.py via the documented `uv run --with datamodel-code-generator python3 code/sdk/schemas/generate.py`, scoped to just this schema's diff (other generated files were reverted -- their regen timestamp bump and one unrelated jwk.py behavior difference from a newer datamodel-code-generator version are out of scope for this change). 2 new tests confirm both paths (default-unverified, explicit-verified); existing receipt_wrapper_tests.py suite (10/10) and the broader test suite pass -- the only 2 pre-existing failures (kb_sd_jwt_intermediate_tests.py, aud/nonce mismatch) reproduce identically on main before this change and are unrelated (tracked separately as google-agentic-commerce#319). Fixes google-agentic-commerce#327
5466886 to
5e914a4
Compare
|
Clean scope — additive, backward-compatible, and it's honest about not trying to solve rail verification itself. Good PR. |
|
recheck |
|
Thanks — appreciated. Kept it scoped deliberately: this flags the gap (issuer self-declared vs. independently confirmed) without pretending to solve rail verification, which is a separate, harder problem outside what a receipt schema can guarantee on its own. |
|
CI status update on this PR's two failing checks: spellcheck — fixed ( Lint Code Base (Super-Linter/Biome) — pre-existing, unrelated to this diff, not fixed here. The failure is entirely inside |
pisp/PISP (Payment Initiation Service Provider), SECP (secp256k1), pyca (pyca/cryptography, the library this PR's signature verification uses), codegen/datamodel (from the generated SDK file's own header comment) -- all real terms, not typos. Verified locally: cspell now reports 0 issues across all 4 files this PR touches.
00e84df to
cbebf0f
Compare
2 participants
What
PaymentReceipt(status="Success")currently asserts payment success purely by producingpsp_confirmation_id/network_confirmation_id— the Python SDK'screate_payment_receipt()self-generates both as a UUID with no payment-rail check, and the MPP sample signs the result without ever calling out to a PSP or network (#327). A downstream party has no way to tell "independently confirmed against the rail" apart from "the issuer declared success and generated two IDs to satisfy the schema."This adds an optional
rail_confirmation_verifiedboolean to the Success receipt schema — additive and backward compatible, absent/false is exactly the behavior every existing caller already gets.create_payment_receipt()now accepts optionalpsp_confirmation_id/network_confirmation_id: omit them and nothing changes; supply real, rail-checked values and the receipt honestly reportsrail_confirmation_verified=true.Deliberately does not try to make the SDK itself perform rail verification — that's business/PSP-specific and out of scope for a spec-level receipt helper. It only stops the receipt from silently implying a check that never happened.
This generalizes the same present-vs-checked distinction this repo's own
negotiation-ref.mdinvariant 5 already establishes — discussed with @giskard09 on #327, who suggested drafting this as a concrete proposal rather than another comment.How it was built
code/sdk/schemas/ap2/payment_receipt.json— new optional field, no changes torequired/oneOf.code/sdk/python/ap2/sdk/generated/payment_receipt.pyvia the documenteduv run --with datamodel-code-generator python3 code/sdk/schemas/generate.py, scoped to just this schema's diff (the run also touched every other generated file's regen timestamp plus one unrelatedjwk.pybehavior difference from a newerdatamodel-code-generatorversion — reverted those, out of scope here).receipt_wrapper.py: two new optional kwargs, bothNone-default.test_create_payment_receipt_defaults_to_unverified,test_create_payment_receipt_with_real_rail_confirmation).Testing
receipt_wrapper_tests.py: 10/10 pass (8 existing + 2 new).code/sdk/python/ap2/tests/suite: 188 passed. The 2 failures inkb_sd_jwt_intermediate_tests.py(aud/nonce mismatch) reproduce identically onmainbefore this change — pre-existing, unrelated, already tracked separately as [Bug]: Python terminal KB-SD-JWT verifier accepts tokens missing aud or nonce #319.ruff check/ruff format --diffclean on all touched files.Fixes #327